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DETAILED ACTION 



Claims 1-13 and 16-22 were rejected in Final Office Action of 10 January 2006. 

A request for continued examination under 37 CFR 1.1 14, including the fee set forth in 
37 CFR 1.17(e), was filed in this application after final rejection. Since this application is 
eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) 
has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 
37 CFR 1.114. Applicant's submission filed on 1 5 May 2006 has been entered. 

Claims 1-13 and 16-28 are pending in this application. Claims 1-13 and 16-28 are 
rejected. 



Duty to Disclose 

A reference cited on form PTO-892, US Patent No. 6,052,520 to Watts, III, shares a 
common assignee with the instant application. This reference qualifies as prior art under 35 
U.S.C. § 102(a) and therefore would not be excluded by the provisions of 35 U.S.C. § 103(c). 
This reference is relevant prior art but has not been submitted to the Office in an Information 
Disclosure Statement. 

A reference cited on form PTO-892, "Reservoir Simulation: Past, Present, and Future" by 
J.W. Watts, SPE, Exxon Production Research Company, was discovered by reviewing the 
prosecution history of patent application 09/712,567 which issued as US Patent 6,928,399, 
assigned to ExxonMobil Upstream Research Company. None of these references have been 
cited in an Information Disclosure Statement. 
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In the interest of compact prosecution, the Examiner respectfully requests that Applicants 
consider the patent and non-patent literature known to and available to the persons identified in 
37 CFR 1.56, which includes the assignee of the application, for the timely submission of 
potentially relevant prior art. 

Claim Objections 

1. Claim 5 is objected to for the use of parentheses in the phrase "wherein a text file (Data 
Definitions File) contains the definitions. . The use of parentheses in the claims is permitted to 
indicate reference numerals in the drawings. See MPEP 608.01(m). The meaning of the text 
"Data Definitions File" within parentheses is unknown. It is unclear whether this presents a 
claim limitation, defines a term, or holds some other meaning. 

2. Claim 18 is objected to because the amendments to the claim do not comply with 37 CFR 
1.121. Specifically, the amendment to claim 18 has deleted the phrase "and any combination 
thereof but there are no markings in the claim listing. In the future, any amendments must fully 
comply with 37 CFR 1.121. 

Appropriate correction is required. 

Claim Interpretation 

In the submission of 15 May 2006, Applicants reiterate certain arguments based on 
interpretations of the claim language which the Examiner has not and still does not find to be 
proper. Therefore, in the interest of compact prosecution, the Examiner explicitly sets forth what 
is believed to be a proper interpretation of the independent claims based on the plain and 
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ordinary meaning of the claim language. Applicants are invited to point out specific errors in 
these interpretations as expressly supported by the claim language, specification, or extrinsic 
evidence. 

Claim 1. A computer system comprising an object-oriented software product, the 
software product containing an object-oriented extensible class hierarchy for the storage 
of [data], the class hierarchy comprising a first set of generic classes representing a 
plurality of object types and a second set of generic classes representing member 
variables for the object types, [the extensible class hierarchy permitting the addition of 
additional object types and additional member variables without any modifications to the 
class hierarchy itself]. 

The phrase "for the storage of transport phenomena simulation data" is a statement of 
intended use that does not specifically define the invention. More specifically, "transport 
phenomena simulation data" is presumed to be, in the parlance of computer software, integers, 
floating precision numbers, bytes, characters, strings, and the like. A system that anticipates the 
claim as interpreted above, storing integers, floating precision numbers, bytes, characters, 
strings, and the like, anticipates a system that stores "transport phenomena simulation data" 
because the only distinguishing characteristic would be the intended use. The structure and 
functionality of the systems would be identical. 

The phrase "the extensible class hierarchy permitting the addition of additional object 
types and additional member variables without any modifications to the class hierarchy itself is 
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logically equivalent to "the extensible class hierarchy does not prevent the addition ..." This 
phrase does not positively recite features of the invention. This language does not require a 
step of "adding additional object types". This phrase is a negative limitation . Although a 
negative limitation is not indefinite per se, this negative limitation is indeed indefinite because it 
is unknown how a "hierarchy" would somehow prevent modifications to itself. It is not apparent 
that a hierarchy, i.e. an arrangement of data, can influence the actions of outside forces to prevent 
its manipulation. This language suffers additional deficiencies under 35 U.S.C. § 112, 1 st 
paragraph, as described below. It is unknown what is meant by this language and therefore, for 
the purposes of examination, the claim is interpreted without this phrase. 

The phrase "extensible" is defined as "Capable of being extended or protruded. Of or 
relating to a programming language or a system that can be modified by changing or adding 
features." (The American Heritage College Dictionary, Fourth Edition, 2004) The Examiner 
submits that an object-oriented computer programming language class hierarchy is 
extensible because one of the defining features of an object-oriented programming language is 
the ability to create new objects, i.e. add features. 

For these reasons, the claim interpretation set forth above is a proper, reasonable, and 
broad interpretation of claim 1 . 

Claim 10. A computer-implemented method of simulating transport phenomena in a 
facility network that models facilities used in the production of hydrocarbons [i.e., a 
"facility network" models facilities used in the production of hydrocarbons], the method 
comprising the steps of: 
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Building a model comprising a facility network [see above] wherein the facility network 
comprises facility instances ["facility instances" are "specified values of facility types, " 
see below] formed from facility types based on a first set of generic classes and member 
variable instances ["member variable instances" are "specified values of member 
variables, " see below] formed from member variables for the facility types based on a 
second set of generic classes, and wherein the first and second set of generic classes are 
part of a class hierarchy that is not modified by the addition of other facility types and 
member variables [i.e., the class hierarchy is what it is, and shall not be modified 
further]', 

Specifying values of the member variables and the facility types for the facility network, 
wherein the specified values of the facility types form facility instances, the specified 
values of the member variables form member variable instances; 

Using [as a function of time, see below] the facility instances and member variable 
instances in a mathematical simulation of transport phenomena within the facility 
network as a function of time; and 

Predicting the behavior of the facilities based on the mathematical simulation. 

For clarity of the official record, this claim appears to define "a first set of generic 
classes" upon which "facility types" are based. Specifying values of the facility types forms 
"facility instances". This claim appears to define "a second set of generic classes" upon which 
"member variables" are based. Specifying values of the member variables forms "member 
variable instances". 
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The phrase "the first and second generic classes are part of a class hierarchy that is not 
modified by the addition of other facility types and member variables" does not appear 
analogous to the "permitting" language recited by claim 1 . Here, the claim neither recites any 
steps of adding other facility types or member variables, nor does the claim invoke the same 
"permitting" type language. Therefore the Examiner interprets this phrase as set forth above 
based on the plain meaning of the phrase "is not modified," as in, "This thing is original; it is not 
modified (by the addition of non-original features) " The phrase is therefore interpreted as set 
forth above. 

Claim 13. A computer-implemented method of simulating transport phenomena in a 
model of a physical system [sic, presumed to mean "simulating transport phenomena in 
a physical system using a model of said physical system"], [the physical system] 
comprising a hydrocarbon-bearing reservoir penetrated by a plurality of wells, the 
plurality of wells connected to surface facilities, the method comprising: 
Discretizing the model of the physical system into a plurality of volumetric cells, wherein 
each volumetric cell is modeled as a node, and adjacent nodes [simulate the] exchange 
[of] fluid through connections between the nodes; 

Using facility instances and member variable instances of a class hierarchy to model the 
nodes and connections in the portion of the discretized model that represents wells and 
surface facilities of the physical system, wherein the class hierarchy comprises a first set 
of generic classes representing facility types utilized to create the facility instances and a 
second set of generic classes representing the member variables for the facility types 
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utilized to create the member variable instances, [the class hierarchy [does not prevent] 
the addition of additional facility types and additional member variables without any 
modifications to the class hierarchy itself]; 

Specifying geometric and transport properties for each node and connection; 
Specifying initial conditions for each node and connection; 

Simulating, as a function of time, the transport phenomena in the discretized physical 
system; and 

Predicting the behavior of the physical system based on the simulation. 

For clarity of the official record, this claim appears to define "a physical system" 
represented by a "model of a physical system." The model of a physical system is "discretized 
... into a plurality of volumetric cells" Each volumetric cell is "modeled as a node" with 
"connections between the nodes " The nodes and connections are modeled by "facility instances 
and member variable instances of a class hierarchy." The claim then presents several limitations 
directed to the nature of that class hierarchy. 

The "facility instances" and "member variable instances," which model the nodes which 
model the volumetric cells which are the result of "discretization" of a model representing a 
physical system, are created from facility types represented by a first set of generic classes and 
member variables represented by a second set of generic classes, respectively. 

The hierarchy does not prevent the addition of additional facility types (represented by a 
first set of generic classes and used to create facility instances) and additional member variables 
(represented by a second set of generic classes and used to create member variable instances) 
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without any modifications to the hierarchy itself. Applicants' apparent definition of "modifying 
the hierarchy" appears to contradict what is conventional and known in the art. Adding 
something to a hierarchy modifies the hierarchy. Adding a child to a family tree modifies the 
family tree and adding a new class to a software class hierarchy modifies the hierarchy. The 
claim language does not, however, require "adding additional facility types". This language 
suffers additional deficiencies under 35 U.S.C. § 112, 1 st paragraph, as described below. It is 
unknown what is meant by this language and therefore, for the purposes of examination, the 
claim is interpreted without this phrase. 

Claim 16. A computer implemented method of modeling [sic, "managing"] a 
hydrocarbon system comprising: 

Accessing an application on a computer system having a first set of generic classes and a 
second set of generic classes associated in a class hierarchy; 

Providing facility types for a hydrocarbon facility network created from the first set of 
generic classes; 

Providing member variables that are associated with at least one of the facility types and 
created from the second set of generic classes, wherein the facility types and the member 
variables do not modify the class hierarchy of the first set of generic classes and the 
second set of generic classes [i.e., the facility types and member variables do not act upon 
the class hierarchy to modify it], 



Application/Control Number: 10/016,619 Page 10 

Art Unit: 2123 

Simulating transport phenomena in the hydrocarbon facility network with facility 
instances created from the facility types and the member variables instances created from 
the member variables; and 

Evaluating the results of the simulation to manage operation of the hydrocarbon system 
[sic, presumably the "hydrocarbon facility network" is somehow related to the 
"hydrocarbon system "]. 

The rationale for the interpretation of claim 16 is deemed to be evident from the 
foregoing discussion. 

Claim 24. A reservoir modeling system comprising a computer-readable medium 
encoded with instructions, the instructions configured to: 

Provide a first set of generic classes and a second set of generic classes associated in a 
class hierarchy; 

Access facility types created from the first set of generic classes; 

Access member variables created from the second set of generic classes that are 
associated with at least one of the facility types, wherein the facility types and the 
member variables do not modify the class hierarchy of the first set of generic classes and 
the second set of generic classes [i.e., the facility types and member variables do not act 
upon the class hierarchy to modify it]; 
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Create a hydrocarbon facility network [sic, "model of" or "simulation of" a hydrocarbon 

facility network] with facility instances created from the facility types and the member 

variables instances created from the member variables; 

Simulate fluid flow in the hydrocarbon facility network; and 

Display the simulation results [for evaluation of the hydrocarbon facility network]. 

The phrase "for evaluation of the hydrocarbon facility network" is a statement of 
intended use. Where the prior art "displays the simulation results," this is sufficient to anticipate 
the entire limitation. 

The issues of patentability under 35 U.S. C. §§ 102 and 103 will be directed toward these 
interpretations of the claims. To distinguish the claimed invention over the prior art, Applicants 
must either persuasively argue that the claim interpretation is somehow improper and 
persuasively argue that the proper interpretation is distinguishable over the prior art, or must 
persuasively argue that the claim interpretation given above is distinguishable over the prior art. 

Claim Rejections - 35 USC § 101 
35 U.S.C. § 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, manufacture, or composition of 
matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions 
and requirements of this title. 

3. Claims 1-9 are rejected under 35 U.S.C. § 101 because the claimed invention is directed 
to non- statutory subject matter. 
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Claims 1-9 are directed to "a computer system comprising an object-oriented software 
product." None of the limitations require, expressly or implicitly, a tangible computer apparatus. 
Therefore these claims are directed to computer software per se and are nonstatutory. 

The previous rejections under 35 U.S.C § 101 of claims 10-13 and 16-22 have been 
withdrawn in response to the amendments to the claims. Applicants' arguments regarding these 
rejections have been fully considered. 

To expedite a complete examination of the instant application the claims rejected under 
35 U.S.C. § 101 (nonstatutory) above are further rejected as set forth below in anticipation of 
applicant amending these claims to place them within the four statutory categories of invention. 

Claim Rejections - 35 USC § 112 
The following is a quotation of the first paragraph of 35 U.S.C. § 1 12: 

The specification shall contain a written description of the invention, and of the manner and process of making 
and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it 
pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best mode 
contemplated by the inventor of carrying out his invention. 

4. Claims 1-9 and 13 are rejected under 35 U.S.C. § 112, first paragraph, as failing to 
comply with the enablement requirement. The claim(s) contains subject matter which was not 
described in the specification in such a way as to enable one skilled in the art to which it pertains, 
or with which it is most nearly connected, to make and/or use the invention. 

MPEP 2164.01(a) lists several factors that can contribute to the determination whether 
experimentation is "undue". These factors include, but are not limited to: 
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• The state of the prior art; 

• The nature of the invention; 

• The level of one of ordinary skill; 

• The existence of working examples; and 

• The quantity of experimentation needed to make or use the invention based on the 
content of the disclosure. 

The limitation of "the extensible class hierarchy permitting the addition of additional 
object types and additional member variables without any modifications to the class hierarchy 
itself prevents a person of ordinary skill in the art from making and using the invention. The 
state of the prior art is such that existing programming languages that support object-oriented 
programming by various implementations define a class hierarchy according to the class types. 
The class hierarchy is a representation of the existing object types. The addition of new object 
types to the hierarchy, through inheritance, derivation, or some other equivalent, necessarily 
changes that class hierarchy. Evidence of working examples of programming languages that 
exhibit the claimed behavior would be appreciated. 

The nature of the invention appears to be a means for simulating transport phenomena 
such as extracting oil from a subterranean hydrocarbon-bearing reservoir, not directly related to 
programming language design. In order to make and use the invention as claimed, a person of 
ordinary skill in the art would be required to invent an undisclosed programming language that 
facilitates this particular behavior, an endeavor unrelated to "simulating transport phenomena". 

The act of designing computer programming languages is highly complex, undertaken 
almost exclusively by highly educated experts in that specific field, and often requires a 
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prohibitive investment in time and money. Programming languages such as Ada have gone 
through numerous versions throughout the years, and can be referred to as Ada95 (1995), Ada83 
(1983), and so on. 

As a result of these considerations, undue experimentation would be required to make 
and use the claimed invention wherein "the extensible class hierarchy" would permit "the 
addition of additional object types and additional member variables without any modifications to 
the class hierarchy itself. 

Claims rejected but not specifically mentioned stand rejected by virtue of their 
dependence. Claim 13 reiterates the limitation discussed above. 



Applicants have previously traversed this rejection, however those arguments were found 
unpersuasive. In the submission of 15 May 2006, Applicants argue primarily that: 

Applicants again submit that the present application complies with the current, well-established legal 
principals related to enablement and that the Examiner has not satisfied the requirements set forth within 
the M.P.E.P. § 2164.01(a) for establishing an enablement rejection for at least the reasons presented in the 
previous response. However, to further prosecution, Applicants have included a Declaration from Stephen 
Netemeyer (herein referred to as "Declaration") to further support that the current application is adequately 
enabling, which is attached as an Exhibit. In the Declaration, Mr. Netemeyer establishes that the 
specification and figures are sufficiently descriptive so as to enable one of ordinary skill in the art to make 
and/or use the invention. In particular, the Declaration includes a statement by Mr. Netemeyer that he is a 
person of ordinary skill in the art. Exhibit, para. 4. Mr. Netemeyer has acknowledged that the test for 
enablement is set forth as being whether one of ordinary skill in the art could make or use the invention 
from the disclosure in the patent coupled with information known in the art without undue experimentation. 
See id. at paras. 5 and 6. In view of this test, Mr. Netemeyer states that the current specification is 
sufficientiy description so as to enable one skilled in the art to make and/or use the invention. See id. at 
para. 7. These statements are clearly supported by at least the portions of the specification cited by Mr. 
Netemeyer. ' 

The Examiner respectfully traverses this argument as follows. 

The Examiner has reviewed the Declaration from Mr. Netemeyer, named inventor in 



this patent application. 
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The test for enablement is whether a hypothetical person of ordinary skill in the art would 
find the disclosure enabling. As a named inventor in this application, it stands to reason that 
Mr. Netemeyer has 1) surpassed the level of ordinary skill in the art by virtue of his position as 
an inventor, 2) has prior knowledge of the invention being disclosed, and 3) has prior knowledge 
of the terminology, interpretations, intentions, and assumptions of the inventors. For these 
reasons, the Examiner finds that the Declaration does not overcome the rejections under 35 
U.S.C. § 112, first paragraph. 

The Examiner has reviewed the portions of the specification cited in the Declaration. 
None of this, however, explains how a person should make and/or use an "extensible class 
hierarchy permitting the addition of additional object types and additional member variables 
without any modifications to the class hierarchy itself as recited by the claim. The Examiner 
maintains that in the technology of computer programming languages, adding something to a 
hierarchy modifies the hierarchy. Adding a child to a family tree modifies the family tree and 
adding a new class to a software class hierarchy modifies the hierarchy. 

Applicants' arguments have been fully considered but have been found unpersuasive. 

The following is a quotation of the second paragraph of 35 U.S.C. § 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

The previous rejections of claims 10-12 and 18 under 35 U.S.C. § 1 12, second paragraph, 
are withdrawn in response to Applicants' remarks and amendments. 
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5. Claim 21 is rejected under 35 U.S.C. § 112, second paragraph, as being indefinite for 
failing to particularly point out and distinctly claim the subject matter which applicant regards as 
the invention. 

The meaning of the phrase "the member variables are be accessed without being having 
to be coded as part of the application" is unknown. 

Claim Rejections - 35 USC §102 
The following is a quotation of the appropriate paragraphs of 35 U.S.C. § 102 that form 
the basis for the rejections under this section made in this Office action: 
A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public 
use or on sale in this country, more than one year prior to the date of application for patent in the United 
States. 

6. Claims 1-5, 8, and 9 are rejected under 35 U.S.C. § 102(b) as being anticipated by "The 
C++ Programming Language, Third Edition" by Bjarne Stroustrup (1997). 

Regarding claim 1, Stroustrup discloses a computer system comprising an object-oriented 
software product (entire document, ex. page 732, section 24.2.5), 

the software product containing an object-oriented extensible class hierarchy for the 
storage of data (entire document, ex. page 732, section 24.2.5; page 736, class "Car" storing 
"eptr" data), 

the class hierarchy comprising a first set of generic classes representing a plurality of 
object types (page 735, "Vehicle," "Car," "Emergency," etc.) 
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and a second set of generic classes representing member variables for the object types 
(page 736, in "Police_car" constructor of class "Police_car", member variable "eptr" represented 
by class "Emergency"). 

In response, Applicants primarily argue that: 

For example, Stroustrup fails to disclose an "extensible class hierarchy permitting the addition of additional 
object types and additional member variables without any modifications to the class hierarchy itself," as 
recited in claim 1, 

The Examiner respectfully traverses this argument as follows. 

The claim language does not require "the addition of additional object types and 
additional member variables without any modifications to the class hierarchy itself" The claim 
requires permitting this step. Applicants have not argued that Stroustrup forbids this behavior, 
merely that it is not disclosed. This argument is unpersuasive because it does not show that 
Stroustrup fails to anticipate the claim language. 

Applicants' arguments have been fully considered but have been found unpersuasive. 

Regarding claim 2, which recites that "the transport phenomena comprises one or more of 
momentum, energy, and mass transport within a subsurface hydrocarbon-bearing reservoir and 
between the subsurface hydrocarbon-bearing reservoir and one or more delivery locations at the 
earth's surface," this language limits claim 1 only indirectly . Claim 1 recites storing "transport 
phenomena simulation data." The limitations of claim 2 further limit the type of "transport 
phenomena," but does not limit the structure or functionality of the system of claim 1 . 
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Therefore, as Stroustrup anticipates claim 1, Stroustrup similarly anticipates claim 2 by 
disclosing, inter alia, storing data (entire document, ex. page 732, section 24.2.5; page 736, class 
"Car" storing "eptr" data). 

In response to the previous rejection of claim 2, Applicants argue primarily that: 

[T]he Rahon and Stroustrup references fail to disclose claimed subject matter, such as "wherein the 
transport phenomena comprises one or more of momentum, energy, and mass transport within a subsurface 
hydrocarbon-bearing reservoir and between the subsurface hydrocarbon-bearing reservoir and one or more 
delivery locations at the earth's surface," as recited in claim 2 . . . 

The Examiner respectfully traverses this argument as follows. 

For the reasons set forth above, the claim language referred to by Applicants only limits 
the scope of claim 1 indirectly and insufficiently to overcome the Stroustrup reference. It 
matters not if the data is energy data, mass data, color data, or poetry data. The system of claim 
1 will store the data by the same mechanisms regardless of the source, context, or type of data 
being stored. 

Applicants' arguments have been fully considered but have been found unpersuasive. 

Regarding claim 3, which recites that "the transport phenomena between a subsurface 
hydrocarbon-bearing reservoir and one or more of the delivery locations comprises one or more 
pathways, the transport pathways comprising at least one of production and injection well types 
and one or more facility types that are linked together to form a facility network through which 
hydrocarbon fluids are transported between the subsurface reservoir and the delivery locations," 
this language limits claims 1 and 2 only indirectly . This claim appears to be directed to 
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"transport phenomena," which similarly to claim 2 does not limit the functionality or structure of 
the system of claim 1 . 

Therefore, as Stroustrup anticipates claims 1 and 2, Stroustrup similarly anticipates claim 

3. 

In response to the previous rejection of claim 3, Applicants argue primarily that: 

[The Rahon and Stroustrup references fail to disclose] "wherein the transport phenomena between a 
subsurface hydrocarbon-bearing reservoir and one or more of the delivery locations comprises one or more 
pathways, the transport pathways comprising at least one of production and injection well types and one or 
more facility types that are linked together to form a facility network through which hydrocarbon fluids are 
transported between the subsurface reservoir and the delivery locations," as recited in claim 3 . . . 

The Examiner respectfully traverses this argument as follows. 

For the reasons set forth above, the claim language referred to by Applicants only limits 
the scope of claims 1 and 2 indirectly and insufficiently to overcome the Stroustrup reference. 

Regarding claim 4, which recites "wherein the facility types contained within the 
transport pathways comprise at least one facility selected from surface flowlines, manifolds, 
separators, valves, pumps, and compressors," this language limits claims 1-3 only indirectly . 

Therefore, as Stroustrup anticipates claims 1-3, Stroustrup similarly anticipates claim 4. 

In response to the previous rejection of claim 4, Applicants argue primarily that: 

[The Rahon and Stroustrup references fail to disclose] "wherein the facility types contained within the 
transport pathways comprise at least one facility selected from surface flowlines, manifolds, separators, 
valves, pumps, and compressors," as recited in claim 4... 

The Examiner respectfully traverses this argument as follows. 
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For the reasons set forth above, the claim language referred to by Applicants only limits 
the scope of claims 1-3 indirectly and insufficiently to overcome the Stroustrup reference. 

Regarding claim 5, which recites "wherein a text file (Data Definitions File) contains the 
definitions of the possible facility types that can be included in a simulation model and the 
definitions of the possible member variables types for each facility type," this claim language 
appears to be entirely unrelated to the previously claimed invention. The language "wherein a 
text file contains" appears to be directed to nonstatutory nonfunctional descriptive material, such 
as software documentation or software code that merely contains a textual description of, 
perhaps, an aspect of the invention. This language refers to the "possible facility types," and 
therefore appears to exclude the "impossible facility types," but it is unknown how to identify 
one from the other. This language refers to possible facility types "that can be included in a 
simulation model," and therefore appears to exclude the possible facility types "that cannot be 
included in a simulation model," but it is unknown how to identify one from the other. 

Of course, this claim language does not require including facility types in a simulation 
model, but instead merely requires the existence, somewhere, in some form, of a text file that 
contains the definitions (describes) possible facility types that, optionally, at any time in the 
past, present, or future, can be included in a simulation model. Similar analysis is appropriate 
for the language "possible member types for each facility type." 

Stroustrup discloses a text file (page 225, section 10.2.2, "Date" class). Because 
Stroustrup also anticipates claims 1-4, in light of the claim language, this disclosure appears to 
fully anticipate the claim. 
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In response to the previous rejection of claim 5, Applicants submit that: 

[The Rahon and Stroustrup references fail to disclose] "wherein a text file (Data Definitions File) contains 
the definitions of the possible facility types that can be included in a simulation model and the definitions 
of the possible member variable types for each facility type," as recited by claim 5. Finally, the Examiner 
appears to have utilized hindsight reconstruction to pick and choose among isolated disclosures to teach the 
claimed subject matter. Hence, the cited references, alone or in combination , does not disclose or suggest 
the claimed subject matter. 

The Examiner respectfully traverses this argument as follows. 

For the reasons set forth above, Stroustrup anticipates claim 5. 

The Examiner respectfully submits that in a patent application presenting claims 
spanning the spectrum from "object-oriented software written in C++" (claim 8), to a text file 
(claim 5), to "simulating transport phenomena in a facility network that models facilities used in 
the production of hydrocarbons" (claim 10), to "transport between a subsurface hydrocarbon- 
bearing reservoir and one or more of the delivery locations comprises one or more transport 
pathways, the transport pathways comprising at least one of production and injection well types 
and one or more facility types that are linked together to form a facility network through which 
hydrocarbon fluids are transported between the subsurface reservoir and the delivery locations" 
(claim 3), any "picking and choosing among isolated disclosures" is the direct and inevitable 
result of the claim language. 

Applicants may consider promoting an expeditious and thorough prosecution by 
presenting a cohesive set of claims that correspond to the substance and import of the disclosed 
inventive concept. 

Applicants' arguments have been fully considered but have been found unpersuasive. 
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Regarding claim 8, Stroustrup discloses software written in C++ (pages 732-733). 

Regarding claim 9, Stroustrup discloses a hierarchy of logically related data (page 735, 
either figure, corresponding implementation illustrated on page 736). 

The Authoritative Dictionary of IEEE Standards Terms, Seventh Edition, provides the 
following definition relied upon for this rejection: 

database A collection of logically related data stored together in one or more computerized files. 

The following is a quotation of the appropriate paragraphs of 35 U.S.C. §102 that form 
the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(e) the invention was described in (1) an application for patent, published under section 122(b), by another filed 
in the United States before the invention by the applicant for patent or (2) a patent granted on an application for 
patent by another filed in the United States before the invention by the applicant for patent, except that an 
international application filed under the treaty defined in section 351(a) shall have the effects for purposes of this 
subsection of an application filed in the United States only if the international application designated the United 
States and was published under Article 2 1 (2) of such treaty in the English language. 

7. Claims 16-28 are rejected under 35 U.S.C. § 102(e) as being anticipated by US Patent 
No. 6,434,435 to Tubel et al. (Tubel). 

Regarding claim 16, Tubel discloses: 

A computer implemented method of modeling a hydrocarbon system ["The 

present invention further relates to oilfield hydrocarbon production management systems 

capable of managing hydrocarbon production from boreholes, " (column 1, lines 31-51)] 

comprising: 

Accessing an application on a computer system having a first set of generic 
classes and a second set of generic classes associated in a class hierarchy [ "[T]he present 
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invention relates to adaptive optimization software system which comprise intelligent 
software objects (hereinafter "ISO ") arranged in a hierarchical relationship whereby the 
goal seeking behavior of each ISO can be modified by ISOs higher in the ISO's 
hierarchical structure. In yet further particularity, the present invention relates to ISOs 
comprising internal software objects including expert system objects, adaptive models 
objects, optimizer objects, predictor objects, sensor objects, and communication 
translation objects. " (column 1, lines 14-30); Tubel discloses at least a first and second 
set of generic classes]; 

Providing facility types for a hydrocarbon facility network created from the first 
set of generic classes ["Each ISO 10 can represent and model physical things..." 
(column 7, lines 30-54); "The present invention's adaptive, object-oriented 
optimization software's user interface, more fully described herein below, initially 
presents a user with an initial set of ISO 10 internal software objects; user then 
configure specific ISOs 10 or groups of ISOs 10 from this initial set of possible internal 
software objects to represent, model, and relate ISO 10 to processes, concrete 
components (e.g., an automobile) or abstract components (e.g. a miles per gallon 
calculation) to represent real life or abstract processes such as plants, procedures, 
ideas, or systems. Mechanical devices, electrical devices, controllable processes, 
abstract calculations, or almost anything to be controlled or optimized can be 
represented by ISO 10." (column 7, line 58 - column 8, line 3, emphasis added); 
"Referring now to FIG. 30, a diagrammatic representation of ISOs 10 in flow and 
hierarchical relationships, ISOs 10 can model and represent any device or group of 
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devices including sensors 200, controllable devices 300, fluid processing devices 400, 
injection devices 500, or any combination thereof ISOs 10 can also model and 
represent more abstract processes such as a single zone like 640a, a group of zones 
such as 640a and 640b, an entire well such as well 640, or an entire field such as wells 
640, 641, and 642. " (column 25, lines 23-40, emphasis added)]; 

Providing member variables that are associated with at least one of the facility 
types and created from the second set of generic classes [ "Expert system objects 12 can 
"remember" by storing data regarding their own operation. These data may be 
accessible to other internal software objects in the same ISO 10 as the expert system 
objects 12 or to other ISOs 10, but may not be directly accessible by the user. " (column 
8, lines 18-24)], 

Wherein the facility types and the member variables do not modify the class 
hierarchy of the first set of generic classes and the second set of generic classes [Whether 
or not Tubel discloses this capability, Tubel does not disclose that facility types and 
member variables are required to modify the class hierarchvl ; 

Simulating transport phenomena in the hydrocarbon facility network with the 
facility instances created from the facility types and the member variables instances 
created from the member variables ["Further, ISO 10, using sensor objects' 25 data, 
predictor objects 18 and adaptive models objects 20, can also simulate and/or predict 
future process performance as well as determine the effectiveness of ISO 's 10 modeling 
of future process performance. " (column 12, lines 6-30, emphasis added)]; and 
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Evaluating the result of the simulation to manage operation of the hydrocarbon 
system ["Using these sensor objects 25, ISO's 10 expert system objects 12, predictor 
objects 18, adaptive models objects 20, and optimizer objects 22 work together to find, 
calculate, interpret, and derive new states for the control variables that result in the 
desired process state (s) or achieve the process goal(s). " (column 7, lines 10-15)]. 

Regarding claim 24, Tubel discloses the limitations of analogous to those of claim 16 and 

further: 

Simulate fluid flow in the hydrocarbon facility network ["As described herein 
above, to accomplish tehse models and representations, two or more ISOs 10 may be 
configured in either flow relationships that model, or representationally correspond to, 
the flow of the material and/or information with is to be controlled, and/or hierarchical 
relationships that define the prioritization and scope relationships between ISOs 10 or 
groups of ISOs 10, e.g., between that which is being modeled. " (column 25, lines 23-40, 
emphasis added); "Within ISO 610f each of ISO 610d and 610e can concurrently be 
"flow" ISOs 10 as well, representing, for example, the flow of hydrocarbons from each 
well into surface platform 645. " (column 25, lines 50-57, emphasis added)]; and 

Display the simulation results for evaluation of the hydrocarbon facility network 
["Although human intervention may modify or override SCADA's 11 management of 
hydrocarbon production, SCAD A 's 11 ability to rapidly and adaptive ly react to complex 
and changing conditions affecting production with a minimum of human intervention 
allows SCADA 11 to automatically detect and adapt to varying control and 
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communication reliability while still achieving its important control operations. " 
(column 26, lines 15-25)]. 

Regarding claim 17, Tubel discloses wherein the simulation models fluid transport 
between a surface facility and a subsurface formation accessed by a well ["Within ISO 61 Of, 
each of ISO 610d and 6I0e can concurrently be "flow" ISOs 10 as well, representing, for 
example, the flow of hydrocarbons from each well into surface platform 645. " (column 25, lines 
50-57)]. 

Regarding claims 18, 25, and 26, Tubel discloses wherein the facility types comprise 
model representations of one or more of surface flowlines, manifolds, separators, valves, pumps, 
and compressors, which represent physical equipment in the flow path between a reservoir and a 
delivery location [ "Controllable devices 300 may include flow control devices familiar to those 
skilled in the hydrocarbon production arts and include valves, pumps, and the like. " (column 22, 
lines 8-38); (column 23, lines 8-41); "Referring now to FIG. 30, a diagrammatic representation 
of ISOs 10 in flow and hierarchical relationships, ISOs 10 can model and represent any device 
or group of devices including sensors 200, controllable devices 300, fluid processing devices 
400, injection devices 500, or any combination thereof ISOs 10 can also model and represent 
more abstract processes such as a single zone like 640a, a group of zones such as 640a and 
640b, an entire well such as well 640, or an entire field such as wells 640, 641, and 642. " 
(column 25, lines 23-40, emphasis added)]. 
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Regarding claim 19, Tubel discloses wherein the simulation models fluid transport 
between surface facilities and a subsurface formation accessed by a plurality of wells ["ISOs 10 
can also model and represent more abstract processes such as a single zone like 640a, a group 
of zones such as 640a and 640b, an entire well such as well 640, or an entire field such as wells 
640, 641, and 642. " (column 25, lines 23-40)]. 

Regarding claim 20, Tubel discloses coding the first set of generic classes representing 
the facility types and the second set of generic classes representing member variables prior to 
loading the application onto the computer system [ "The present invention 's adaptive, object- 
oriented optimization software's user interface, more fully described herein below, initially 
presents a user with an initial set of ISO 10 internal software objects; user then configure 
specific ISOs 10 or groups of ISOs 10 from this initial set of possible internal software objects to 
represent, model, and relate ISO 10 to processes, concrete components (e.g., an automobile) or 
abstract components (e.g. a miles per gallon calculation) to represent real life or abstract 
processes such as plants, procedures, ideas, or systems. Mechanical devices, electrical devices, 
controllable processes, abstract calculations, or almost anything to be controlled or optimized 
can be represented by ISO 10. " (column 7, line 58 - column 8, line 3, emphasis added)]. 

Regarding claims 21 and 28 Tubel discloses using a text file configured to define the 
facility types and the member variables for use in the simulation, wherein the text file contains 
descriptive text and facility types, and instruction configured to access a descriptive text file that 
defines at least one of the facility types and member variables for use in the simulation [ "ISOs 
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10 comprise internal software objects; in the preferred embodiment, the present invention uses a 
software programming methodology known as object-oriented programming, typically 
implemented using a computer language such as SmallTalk^* or C++, to implement the ISO 's 
10 internal software objects, thus creating an adaptive, object-oriented optimization software 
system. " (column 6, lines 53-59); regarding simulation, "Further, ISO 10, using sensor objects' 
25 data, predictor objects 18 and adaptive models objects 20, can also simulate and/or predict 
future process performance as well as determine the effectiveness of ISO's 10 modeling of 
future process performance. " (column 12, lines 6-30, emphasis added)]; 

Regarding claims 22, 23, and 27, Tubel discloses creating facility instances from the 
facility types, utilizing the facility instances to represent components of the hydrocarbon facility 
network for the simulation, and managing the hydrocarbon system based on the simulation, and 
constructing logic that dynamically controls the behavior of facilities in the hydrocarbon facility 
network during a simulation run [ "The present invention 's adaptive, object-oriented optimization 
software 's user interface, more fully described herein below, initially presents a user with an 
initial set of ISO 10 internal software objects; user then configure specific ISOs 10 or groups of 
ISOs 10 from this initial set of possible internal software objects to represent, model, and relate 
ISO 10 to processes, concrete components (e.g., an automobile) or abstract components (e.g. a 
miles per gallon calculation) to represent real life or abstract processes such as plants, 
procedures, ideas, or systems. Mechanical devices, electrical devices, controllable processes, 
abstract calculations, or almost anything to be controlled or optimized can be represented by 
ISO 10. " (column 7, line 58 - column 8, line 3, emphasis added)]. 
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Claim Rejections - 35 USC §103 
The previous rejections of claims 16-22 under 35 U.S.C. § 103 have been withdrawn in 
light of Applicants' remarks and amendments. Applicants' arguments directed to those 
rejections have been fully considered but are moot in light of the new grounds of rejection. 

The following is a quotation of 35 U.S.C. § 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art 
are such that the subject matter as a whole would have been obvious at the time the invention was made to 
a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be 
negatived by the manner in which the invention was made. 

The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 
(1966), that are applied for establishing a background for determining obviousness under 35 
U.S.C. § 103(a) are summarized as follows: 

1 . Determining the scope and contents of the prior art. 

2. Ascertaining the differences between the prior art and the claims at issue. 

3. Resolving the level of ordinary skill in the pertinent art. 

4. Considering objective evidence present in the application indicating obviousness 
or nonobviousness. 

This application currently names joint inventors. In considering patentability of the 
claims under 35 U.S.C. § 103(a), the examiner presumes that the subject matter of the various 
claims was commonly owned at the time any inventions covered therein were made absent any 
evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out 
the inventor and invention dates of each claim that was not commonly owned at the time a later 



Application/Control Number: 10/016,619 Page 30 

Art Unit: 2123 

invention was made in order for the examiner to consider the applicability of 35 U.S.C. § 103(c) 
and potential 35 U.S.C. § 102(e), (f) or (g) prior art under 35 U.S.C. § 103(a). 

8. Claims 6 and 7 are rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Stroustrup as applied to claim 1 above, and further in view of US Patent No. 6,842,725 to Sarda. 

Regarding claim 6, Stroustrup discloses the limitations of claim 1 . 

Stroustrup does not expressly teach the graphical user interface. 

Sarda teaches a method for modeling fluid flows in a hydrocarbon reservoir (column 2, 
lines 5-18). Sarda teaches a user interface wherein a user defmes the specific well network for 
the reservoir [detailed description, section 5, "Simulation input data", "The data relative to the 
well are: its geometry, in the form of a series of connected segments^ and] the imposed flow 
rates, in the form of a curve giving the imposed flow rate as a function of time. " (column 8, lines 
28; 53-59)]. Sarda teaches a graphical interface concerning the well ["A well is a series of 
connected segments that intersect the network fractures. The geometric representation of a well 
is therefore a 3D broken line. " (column 5, lines 60-63)]. Sarda both suggests and implies the use 
of a graphical user interface for defining the specific network of wells and facility objects to 
simulate transport phenomena into and out of a specific hydrocarbon-bearing reservoir. 

Regarding claim 7, Sarda discloses a graphical user interface (column 5, lines 60-63). 
Sarda does not expressly forbid "a user of the computer [from defining] the additional member 
variables that extend the functionality of the computer system in a user-customizable manner." 

Sarda and Stroustrup are analogous art because both are drawn to computer software. 
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It would have been obvious to a person of ordinary skill in the art at the time of 
Applicants' invention to combine a graphical user interface as taught by Sarda with the 
programming language of Stroustrup by implementing a graphical user interface using a 
programming language. 

The motivation for doing so is expressly found in Sarda [ "The main advantage of the 
method according to the invention in relation to methods applied to a finely meshed real fracture 
network lies, as detailed in the description hereafter, in a considerable reduction in a number of 
meshes centered on fracture nodes used to solve equation (1). The simulation rate saving in 
relation to prior fine-mesh methods can be confirmed to be greater than the simple arithmetical 
ratio of the number of meshes used in both cases. " (column 3, lines 22-30)] as well as expressly 
found in Stroustrup, such as an enhanced ability to understand how the model works [ "The point 
about modeling reality is not to slavishly follow what we see but rather to use it as a starting 
point for design, a source of inspiration, and an anchor to hold on to when the intangible nature 
of software threatens to overcome our ability to understand our programs. " (page 734)]. 

Therefore, it would have been obvious to combine Sarda with Stroustrup to obtain the 
invention as specified in claims 6 and 7. 

9. Claim 7 is rejected under 35 U.S.C. § 103(a) as being unpatentable over Stroustrup as 
applied to claim 1 above, and further in view of "Design Patterns: Elements of Reusable Object- 
Oriented Software" by Erich Gamma, Richard Helm, Ralph Johnson, and John Viissides 
(Vlissides, 1995). 
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Regarding claim 7, Stroustrup does not expressly teach a graphical user interface through 
which a user can define additional data members. 

Vlissides teaches a design pattern for object-oriented software called the "Factory 
Method" (page 107) wherein an exemplary use is shown (page 107) depicting, in flowchart form, 
a user interface wherein a user of a computer system can create additional data objects 
{Documents) by using a graphical user interface. Vlissides shows an exemplary "user 
customized" data member [MyApplication] that contains its own user-customized 
CreateDocumentQ member Sanction. 

It would have been obvious to a person of ordinary skill in the art at the time of 
Applicants' invention to combine the Factory Method design pattern taught by Vlissides, 
especially in light of Vlissides' examples, with the object-oriented programming language taught 
by Stroustrup to achieve a graphical user interface through which a user can define additional 
data members. The combination could be achieved by using a user-customized CreateFacilityQ 
function, wherein the nature of the problem to be solved would motivate a person of ordinary 
skill in the art to customize that function to the particular intended use at hand. Motivation to 
combine is expressly taught by Vlissides [ "Use the Factory Method pattern when: a class can 7 
anticipate the class of objects it must create; a class wants its subclasses to specify the objects it 
creates; classes delegate responsibility to one of several helper subclasses, and you want to 
localize the knowledge of which helper subclass is the delegate. " (page 108) All these reasons 
relate directly to customization of the classes at a later point in time.]. 



Application/Control Number: 10/016,619 Page 33 

Art Unit: 2123 

10. Claims 10-12 are rejected under 35 U S C. § 103(a) as being unpatentable over Sarda in 
view of Stroustrup. 

Regarding claim 10, Sarda teaches a method for modeling fluid flows in a hydrocarbon 
reservoir (column 2, lines 5-18) including a facility network ["A well is a series of connected 
segments that intersect the network fractures. The geometric representation of a well is 
therefore a 3D broken line. " (column 5, lines 60-63)]. Sarda teaches a user interface wherein 
user specifies values of the member variables for each facility [detailed description, section 5, 
"Simulation input data", "The data relative to the well are: its geometry, in the form of a series 
of connected segments^ and] the imposed flow rates, in the form of a curve giving the imposed 
flow rate as a function of time. " (column 8, lines 28; 53-59)]. Sarda teaches using the specified 
values in a mathematical simulation of transport phenomena within the facility network as a 
function of time, thereby predicting the behavior of the facilities based on the simulation [ "In 
order to simulate a well test, whatever the medium, this equation has to be solved in space and in 
time. Discretization of the reservoir (mesh pattern) is therefore performed and solution of the 
problem consists in finding the pressures of the meshes with time, itself discretized in a certain 
number of time intervals. " (column 2, lines 24-47)]. 

Sarda does not explicitly disclose the software design of the method for modeling fluid 

flows. 

Stroustrup discloses "building a model comprising a facility network [...] formed from 
facility types based on a first set of generic classes and member variable instances formed from 
member variables for the facility types based on a second set of generic classes, and wherein the 
first set and second set of generic classes are part of a class hierarchy that is not modified by the 
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addition of other facility types and member variables," (pages 735-738 and as cited above). This 
limitation refers to basic concepts of object-oriented programming. Whether or not a class 
hierarchy is modified at a later time is impossible to compare to the teachings of the prior art. 

It would have been obvious to a person of ordinary skill in the art to implement the model 
taught by Sarda in object-oriented software because the advantages of object-oriented software 
are well known to persons of ordinary skill. Motivation to do so is explicitly taught by 
Stroustrup, such as an enhanced ability to understand how the model works [ "The point about 
modeling reality is not to slavishly follow what we see but rather to use it as a starting point for 
design, a source of inspiration, and an anchor to hold on to when the intangible nature of 
software threatens to overcome our ability to understand our programs. " (page 734)]. 

In response, Applicants argue primarily that: 

In Sarda, a method of modeling fluid flows in the fractured multilayer porous medium by accounting for 
the real geometry of the fracture network and the local exchanges with the porous matrix is described, (cit. 
omitted) Clearly, Sarda does not provide or teach building a model having a facility network, much less, 
predicting the behavior of the facilities based on the mathematical simulation. 

Stroustrup describes the C++ concepts for creating built-in types to organize classes and take advantage of 
the relationships, (cit. omitted) In particular, Stroustrup describes that inheritance may be utilized to 
represent the hierarchical relationships directly, (cit. omitted) While Stroustrup describes classes having 
subclasses, it does not describe "the first set and second set of generic classes are part of a class hierarchy 
that is not modified by the addition of other facility types and member variables," as recited in claim 10. 

The Examiner respectfully traverses this argument as follows. 

Applicants' arguments appear to misconstrue how the references have been applied. 
Sarda teaches a facility network, as cited, and Sarda teaches predicting the behavior of facilities 
based on a mathematical simulation, as cited. 

Regarding Applicants' analysis of the Stroustrup reference, although it is disclosed that 
the class hierarchy may be modified, there is no requirement in the reference that the hierarchy 
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must be modified beyond what is shown . A person might, for example, acknowledge that the 
hierarchy may be further modified, but choose to use the hierarchy as disclosed by Stroustrup. 
As such, according to the plain meaning of the claim language, Stroustrup anticipates the recited 
feature. 

Applicants' arguments have been fully considered but have been found unpersuasive. 

Regarding claim 1 1, Sarda teaches that the facility network is part of a larger simulation 
model, with said facility network is configured to exchange fluids with at least one other part of 
the simulation model [fluid from the reservoir is transferred via the series of connected segments 
that form the facility network of the well (column 2, lines 55-67)]. 

Regarding claim 12, Sarda teaches that the simulation model comprises a facility network 
[ "A well is a series of connected segments that intersect the network fractures. The geometric 
representation of a well is therefore a 3D broken line. " (column 5, lines 60-63)] and a 
hydrocarbon-bearing formation ["Discretization of the reservoir (mesh pattern) is therefore 
performed and solution of the problem consists in finding the pressures of the meshes with time, 
itself discretized in a certain number of time intervals. " (column 2, lines 43-47)]. 

11. Claim 13 is rejected under 35 U.S.C. § 103(a) as being unpatentable over US Patent No. 
6,434,435 to Tubel et al. (Tubel) in view of Sarda, and further in view of Stroustrup. 
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Regarding claim 13, Tubel teaches an object-oriented software for control of a 
hydrocarbon production system (column 1, lines 14-50). Although Tubel is primarily concerned 
with the control of such a system, the disclosed invention can also perform in a simulation mode 
[ "...in the simulation mode, simulated and/or calculated sensor and actuator data may be used 
in place of data from real-world sensors and actuators. Simulation of real or abstract systems 
occurs by having an ISO 10 evaluate or interrogate a model of a real or abstract thing or system 
or evaluate and/or interact with rules associated with the real or abstract thing. " (column 12, 
lines 6-18)]. 

Tubel teaches a predicting the behavior of (and therefore simulating) a hydrocarbon- 
bearing reservoir penetrated by a plurality of wells and surface facilities, the plurality wells 
connected to surface facilities ["...the present invention relates to management of hydrocarbon 
production from a single production well (e.g., only well 642) or from a group of wells, shown in 
FIG 28 as well 640. well 64 1. and well 642 ." (column 23, lines 8-15); "Referring still to FIG. 
28, as is well known in the art a given well may be divided into a plurality of separate zones, 
such as zone 640a, zone 640b, and zone 640c. Such zones may be positioned in a single vertical 
well such as well 640 associated with surface platform 645. or such zones may result when 
multiple wells are linked or otherwise joined together (not shown in FIG. 28). " (column 26, lines 
52-58, emphasis added)]. 

Tubel teaches using objects and variables in a class hierarchy to model the wells and 
surface facilities ["Referring now to FIG. 30, a diagrammatic representation of ISOs JO in flow 
and hierarchical relationships, ISOs 10 can model and represent any device or group of devices 
including sensors 200, controllable devices 300, fluid processing devices 400, injection devices 
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500, or any combination thereof. ISOs 10 can also model and represent more abstract processes 
such as a single zone like 640a, a group of zones such as 640 a and 640b, an entire well such as 
well 640, or an entire field such as wells 640, 641, and 642. " (column 25, lines 23-3 1)]. 

Tubel does not teach discretizing the reservoir into a plurality of volumetric cells, each 
modeled as nodes, and simulating the exchange of fluid between those nodes. 

Sarda teaches discretizing the reservoir into a mesh pattern (consisting of interconnected 
nodes) used to model the reservoir by finding the pressure of the oil contained therein as a 
function of time (column 2, lines 24-47). In this method, the model simulates the flow of fluid 
through a porous medium, accounting for the real geometry of the fracture network (found in the 
reservoir) and thus simulates the interactions between the pressure and flow rate variations in a 
well running across the medium (column 2, lines 55-67). Sarda teaches specifying initial 
conditions for each node and connection (column 4, lines 33-64). 

It would have been obvious to a person of ordinary skill in the art at the time of 
Applicants' invention to combine Sarda' s method for modeling the flow of fluid in a reservoir 
with Tubel' s object-oriented method of modeling a facility network. The combination could be 
achieved by operating Tubel' s method in simulation mode, wherein the data calculating the 
transport phenomena of the underground reservoir is supplied by Sarda' s method and delivered 
to the sensors and actuators modeled by Tubel. Motivation to combine would be found in the 
knowledge of a person of ordinary skill in the art as well as the nature of the problem to be 
solved; Tubel' s simulation mode requires calculated sensor and actuator data while the results of 
Sarda' s model provide an efficient and accurate representation of the transport phenomena that 
would be detected by Tubel' s sensors. 
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Tubel in view of Sarda does not explicitly teach the claimed software object hierarchy. 

Stroustrup discloses a computer programming language that implicitly discloses the use 
of a modern computer system comprising memory means, storage means, and software created 
using the C++ programming language. 

Stroustrup discloses a class hierarchy (page 735, either figure) comprising a first set of 
generic classes representing a plurality of object types (example: Car or Truck) and a second set 
of generic classes representing member variables for the object types ["The 'plain' cars and 
trucks are initialized with Vehicle::eptr zero; the others are initialized with Vehicle::eptr 
nonzero. " (page 736) Also, example: Police car, class definition of Police car] and wherein 
the hierarchy is designed to be expanded as necessary [section 243. 2 A Dependencies within a 
Class Hierarchy; "If however, the intent is to provide a framework into which a later 
programmer can add code, then virtual functions are often an elegant mechanism for achieving 
this../' (page 738)]. 

It would have been obvious to a person of ordinary skill in the art at the time of 
Applicants' invention to combine Tubel in view of Sarda with the class hierarchy capable of 
storing data as taught by Stroustrup. The combination could be achieved by representing the 
volumetric cells of Tubel in view of Sarda as the objects (storing the appropriate simulation data) 
and methods of a class hierarchy as taught by Stroustrup. Motivation to do so is explicitly taught 
by Stroustrup, such as an enhanced ability to understand how the model works [ " The point about 
modeling reality is not to slavishly follow what we see but rather to use it as a starting point for 
design, a source of inspiration, and an anchor to hold on to when the intangible nature of 
software threatens to overcome our ability to understand our programs. " (page 734)]. 
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In response, Applicants argue primarily that: 

Tubel and Sarda fail to disclose "using facility instances and member variable instances of a class 
hierarchy to model the nodes and connections in the portion of the discretized model that represents wells 
and surface facilities of the physical system, wherein the class hierarchy comprises a first set of generic 
classes representing facility types utilized to create the facility instances and a second set of generic classes 
representing the member variables for the facility types utilized to create the member variable instances, the 
class hierarchy permitting the addition of additional facility types and additional member variables without 
any modifications to the class hierarchy itself," as recited in claim 13 . . . 

Indeed, Tubel describes changing the class hierarchy. Similarly, as discussed above, Sarda 
reference discloses the modeling of a well test in a fractured reservoir. 

[Arguments directed to the Stroustrup reference are reiterated.] 

The Examiner respectfully traverses this argument as follows. 

Applicants' observation that Tubel describes changing the class hierarchy is noted. The 
claim language does not exclude changing the class hierarchy. The claim language requires 
permitting the addition of facility types and member variables without modifications to the 
hierarchy. The simple fact that Tubel describes changing the class hierarchy is not evidence that 
Tubel forbids the addition of facility types and member variables without modifications to the 
hierarchy. 

Applicants' arguments regarding the Sarda and Stroustrup reference have been addressed 

above. 

Applicants' arguments have been fully considered but have been found unpersuasive. 



Conclusion 

Art considered pertinent by the examiner but not applied has been cited on form PTO- 

892. 

US Patent No. 6,052,520 to Watts, III, shares a common assignee with the instant 
application and discloses subject matter related to the simulation of a hydrocarbon reservoir. 
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"Reservoir Simulation: Past, Present, and Future" by J.W. Watts, SPE, Exxon Production 
Research Company discloses a description of the state of the art in simulation of hydrocarbon 
reservoirs, circa 1997. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Jason Proctor whose telephone number is (571) 272-3713. The 
examiner can normally be reached on 8:30 am-4:30 pm M-F. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Paul Rodriguez can be reached at (571) 272-3753. The fax phone number for the 
organization where this application or proceeding is assigned is (571) 273-8300. 

Any inquiry of a general nature or relating to the status of this application should be 
directed to the TC 2100 Group receptionist: 571-272-2100. Information regarding the status of 
an application may be obtained from the Patent Application Information Retrieval (PAIR) 
system. Status information for published applications may be obtained from either Private PAIR 
or Public PAIR. Status information for unpublished applications is available through Private 
PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. 
Should you have questions on access to the Private PAIR system, contact the Electronic Business 
Center (EBC) at 866-217-9197 (toll-free). 



Jason Proctor 
Examiner 
Art Unit 2123 




